| Time |
Nick |
Message |
| 00:05 |
|
kabou joined #minetest |
| 00:06 |
|
GoodClover joined #minetest |
| 00:08 |
|
z812 joined #minetest |
| 00:10 |
|
wolfshappen joined #minetest |
| 00:11 |
|
Fulgen joined #minetest |
| 00:13 |
|
ROllerozxa joined #minetest |
| 00:14 |
|
dabbill joined #minetest |
| 00:14 |
|
erle joined #minetest |
| 00:15 |
|
TheMaster joined #minetest |
| 00:27 |
|
RhineDevil^ joined #minetest |
| 00:27 |
|
Boingo joined #minetest |
| 00:54 |
|
JerryXiao joined #minetest |
| 01:19 |
|
RhineDevil joined #minetest |
| 01:25 |
|
Verticen joined #minetest |
| 01:28 |
|
RhineDevil joined #minetest |
| 01:55 |
|
RhineDevil joined #minetest |
| 02:10 |
|
redquasar_ joined #minetest |
| 02:13 |
|
Sokomine joined #minetest |
| 02:36 |
|
Gustavo6046 joined #minetest |
| 02:37 |
|
Gustavo6046 joined #minetest |
| 02:39 |
|
Gustavo6046 joined #minetest |
| 02:46 |
|
Extex joined #minetest |
| 03:12 |
|
fluxionary joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:01 |
|
Hawk777 joined #minetest |
| 04:37 |
|
fling joined #minetest |
| 05:01 |
|
riff-IRC joined #minetest |
| 05:10 |
|
grouinos joined #minetest |
| 05:43 |
|
fling joined #minetest |
| 05:44 |
|
calcul0n joined #minetest |
| 05:58 |
|
Lesha joined #minetest |
| 06:07 |
|
InFerNo_ joined #minetest |
| 06:47 |
|
fling joined #minetest |
| 07:49 |
|
fling joined #minetest |
| 07:56 |
|
riff-IRC joined #minetest |
| 08:04 |
|
riff-IRC joined #minetest |
| 08:08 |
|
riff-IRC joined #minetest |
| 08:09 |
|
lemonzest joined #minetest |
| 08:23 |
|
riff-IRC joined #minetest |
| 08:53 |
|
fling joined #minetest |
| 09:42 |
|
specing_ joined #minetest |
| 09:59 |
|
fling joined #minetest |
| 10:54 |
|
definitelya joined #minetest |
| 11:38 |
|
harry-wood joined #minetest |
| 11:44 |
|
wolfshappen joined #minetest |
| 11:53 |
MTDiscord |
<MisterE> Erle |
| 11:53 |
MTDiscord |
<MisterE> Nodecore particles alert you that you have discovered a craft |
| 11:53 |
MTDiscord |
<MisterE> They are completely essential |
| 11:54 |
MTDiscord |
<Warr1024> It's not literally impossible to play without, but it's a significant handicap. |
| 11:54 |
erle |
oh interesting |
| 11:54 |
erle |
i did not know that |
| 11:54 |
MTDiscord |
<MisterE> Please, be more careful when suggesting that yet another feature should be made entirely optional |
| 11:55 |
MTDiscord |
<MisterE> Now, perhaps a particle veiw range wold be ok |
| 11:55 |
MTDiscord |
<Warr1024> Players configuration should be on an informed consent basis. Don't add options unless game devs are able to inform and recommend. |
| 11:56 |
erle |
i still believe that the better thing would be to actually optimize particle rendering |
| 11:56 |
MTDiscord |
<MisterE> Which, hey, a particle view range could be set to 0, and thats ok |
| 11:56 |
MTDiscord |
<Warr1024> I have considered a particle reduction setting that would just add a multiplier to the particle spawner amounts and a probability to lone particle spawns |
| 11:57 |
MTDiscord |
<MisterE> Because the implicit assumption is that it shouldn't be 0 |
| 11:57 |
MTDiscord |
<Warr1024> Yes making people not feel compelled to disable particles would be the clear win :-) |
| 11:57 |
erle |
MisterE Warr1024 look at irrlicht's examples/08.SpecialFX/main.cpp – it can do dynamic shadows and spam particles on potato GPU. and at least the particle thing is relatively easy … with the exception that the particle system is *less powerful* than what minetest needs (the vertical thing i think) |
| 11:57 |
MTDiscord |
<oneplustwo> It would be convenient for me specifically though, I'm tired of joining servers with a lot of useless particles and getting an unplayable experience |
| 11:58 |
erle |
regardless i have heard stories of servers where people basically stopped plading in rain |
| 11:58 |
MTDiscord |
<Warr1024> The point is to make experiences that have a lot of particles remain playable. |
| 11:58 |
erle |
because of client lag |
| 11:58 |
erle |
stopped playing |
| 11:58 |
MTDiscord |
<Warr1024> If a server operator wants to give you a bad experience, we can't add settings to MT to disable that |
| 11:58 |
MTDiscord |
<oneplustwo> Should still be an option imo, not everyone needs or wants particles |
| 11:58 |
|
qur joined #minetest |
| 11:59 |
MTDiscord |
<Warr1024> I already have rain particles effectively disabled in my client. |
| 11:59 |
erle |
how |
| 11:59 |
erle |
you also have a cheat client ig? |
| 11:59 |
MTDiscord |
<Warr1024> I don't play in those servers. |
| 11:59 |
erle |
show |
| 11:59 |
erle |
pls |
| 12:01 |
MTDiscord |
<Warr1024> You ... want me to show you how I don't play on those servers? I don't have a special technique or anything for it. |
| 12:03 |
|
fling joined #minetest |
| 12:06 |
MTDiscord |
<oneplustwo> "joke" |
| 12:06 |
|
proller joined #minetest |
| 12:08 |
erle |
show me how you do not play senpai |
| 12:09 |
MTDiscord |
<oneplustwo> has anyone definitively cracked the code on why mcl2 performance is so bad? |
| 12:10 |
|
independent56 joined #minetest |
| 12:10 |
independent56 |
My server refuses to start. Is the old data storage deprecated? https://pastebin.com/2hrBejVT |
| 12:11 |
MTDiscord |
<ROllerozxa> old mod storage backend shouldn't be the cause of the issue per se, I'd rather focus on the error... uh, in builtin vector?? |
| 12:13 |
erle |
<MTDiscord> <oneplustwo> has anyone definitively cracked the code on why mcl2 performance is so bad? |
| 12:13 |
erle |
yes |
| 12:13 |
erle |
cora has |
| 12:13 |
erle |
there are multiple reasons |
| 12:14 |
MTDiscord |
<ROllerozxa> too many ABMs? |
| 12:14 |
MTDiscord |
<ROllerozxa> or something else |
| 12:15 |
|
Fixer joined #minetest |
| 12:15 |
erle |
i can tell you a few |
| 12:15 |
MTDiscord |
<Warr1024> With a project with that kind of scope, it may be more efficient to ask if there are any reasons they haven't hit. |
| 12:19 |
MTDiscord |
<ROllerozxa> erle: please do! |
| 12:20 |
erle |
look, here are the things fixed in mineclonia: fire spread used timers (i.e. exponential memory consumption), ender chests where entities (and not nodes, thus spamming them would lag the game), player properties would be sent 30 times per second per player, burning animation was sent to client with 60hz, players could be on fire multiple time (thus sending a lot of traffic about burning animation, over 1MB/s), HUD flags were sent |
| 12:20 |
erle |
even if they had not been changed |
| 12:21 |
independent56 |
I do probably have too much ABMs |
| 12:21 |
erle |
furthermore, cora fixed the following, but they are not in mineclonia (possible in mineclone2, i have not looked): nether dust simulating each particle separately instead of using particle spammers … and i guess a bunch more |
| 12:22 |
MTDiscord |
<Warr1024> Some of those don't sound too bad, while others there are real slack jawed head scratchers. |
| 12:22 |
|
proller joined #minetest |
| 12:23 |
erle |
also mineclone2 0.71 had enchanted armor/tools have 20kb of metadata each or so which meant laaaaag |
| 12:23 |
MTDiscord |
<Warr1024> Like how do you even consider sending an animation at 60hz over the network? |
| 12:23 |
erle |
Warr1024 simple, some people LOVE globalsteps |
| 12:23 |
MTDiscord |
<ROllerozxa> oh man |
| 12:23 |
erle |
i have withheld the names to protect the guilty but you can do git blame |
| 12:23 |
erle |
:P |
| 12:23 |
MTDiscord |
<Warr1024> I ain never seen a globalstep at 60hz tho |
| 12:23 |
MTDiscord |
<ROllerozxa> git blame never lies |
| 12:24 |
MTDiscord |
<Warr1024> I love globalsteps too, but I usually use them to improve performance, not the other way around... |
| 12:24 |
rubenwardy |
independent56: do you have a mod that's doing `vector = nil` |
| 12:24 |
independent56 |
No idea |
| 12:24 |
rubenwardy |
do you have any custom mods |
| 12:24 |
erle |
i think some devs in mcl2 basically saw something vaguely related to a player and were like “yep let's do some work in a global step that's rarely relevant, but just to be sure let's do it very often” |
| 12:24 |
independent56 |
Yes, like britsignals, but all are decoration for now |
| 12:25 |
independent56 |
It might be portal rail, looking at world.mt |
| 12:25 |
erle |
Warr1024 have you ever heard of “immediate mode GUI”? people who like to re-render everything in every frame because caching is just too hard? it's stuff like that that appeals to some type of programmers. |
| 12:25 |
MTDiscord |
<Warr1024> I have like 30 registered playersteps in NodeCore, but I don't see anywhere near that kind of packet rate. |
| 12:25 |
independent56 |
Apparently not :-/ |
| 12:26 |
MTDiscord |
<Warr1024> Immediate mode gui makes sense in some context but not over a network :-D |
| 12:26 |
erle |
Warr1024 this one https://github.com/ocornut/imgui |
| 12:26 |
MTDiscord |
<Warr1024> Might as well play MT over VNC using the raw encoding |
| 12:26 |
independent56 |
The thing is, i haven't added any mods, just updated britsignals. |
| 12:27 |
erle |
last time i checked, imgui was a collossal fraud. and i say fraud, because “fast” was a proven lie. |
| 12:27 |
rubenwardy |
imgui is designed for making tools, it doesn't need to be the fastest |
| 12:28 |
independent56 |
Note that this error happens before any logs from loading mods appear |
| 12:28 |
erle |
rubenwardy it's the level of fraud where the framerate drops to less than 5fps as soon as you select a font that has a bit more than latin-1 coverage, which is abysmal for a GUI toolkit nowadays. |
| 12:28 |
MTDiscord |
<Warr1024> There's no such thing as a fast or slow thing without an application or context. Redrawing everything every frame does make sense if everything is changing, or could change and the cost of determining what's affected is more than the cost of just rendering it all. |
| 12:29 |
rubenwardy |
independent56: the thing you fail to mention is britsignals is your mod |
| 12:29 |
independent56 |
It is, sorry |
| 12:29 |
independent56 |
But disabling it has no effect |
| 12:29 |
erle |
Warr1024 yeah, the thing is, with 2d widgets it's almost always not very expensive to determine what needs to be re-rendered |
| 12:29 |
MTDiscord |
<Warr1024> I've made visuals that render everything every frame and run into the font rendering problem, and my solution has largely been just to prerender and memoize glyphs as a special case. The approach itself is still sound. |
| 12:30 |
erle |
memoizing surely works |
| 12:30 |
independent56 |
Should i migrate my mod storage? |
| 12:30 |
erle |
i have seen similar things with sdl and pygame. a coworker complained to me that pygame was slow. turned out he just did not know about dirty rectangles, |
| 12:30 |
rubenwardy |
mod storage won't be causing that issue |
| 12:30 |
independent56 |
I did accidently run git pull in the minetest directory whilst trying to updaye brtisignals |
| 12:31 |
erle |
independent56 that may be an issue. you need builtin lua stuff to correspond to your minetest binary. |
| 12:31 |
MTDiscord |
<Warr1024> But there's an order of magnitude difference between repeatedly shipping the same data over your PCIe bus vs doing the same over the internet :-D |
| 12:31 |
independent56 |
I'll recmopile then |
| 12:31 |
erle |
independent56 do a git checkout so that the builtin lua is at the same version of your binary, then report back |
| 12:31 |
independent56 |
better idea |
| 12:31 |
|
debiankaios joined #minetest |
| 12:31 |
erle |
i think my approach is a bit better hehe |
| 12:32 |
MTDiscord |
<Warr1024> If it were me I'd just update everything and recompile so they're both in sync AND both latest. |
| 12:32 |
Oblomov |
btw weren't there a couple of issues open on the mt engine about sending unnecessary packets? |
| 12:32 |
MTDiscord |
<Warr1024> Depends on how painful compiling is for ya |
| 12:32 |
independent56 |
Quite simple. One command |
| 12:32 |
independent56 |
And a few minutes |
| 12:32 |
Oblomov |
oh lol and obviously they're from Warr1024 ;-) https://github.com/minetest/minetest/issues/9934 |
| 12:32 |
independent56 |
and a few more |
| 12:33 |
MTDiscord |
<Warr1024> I opened a bug once about obj:set_properties, I think it got paramatted, so I've been relying on a NodeCore-layer workaround since. |
| 12:33 |
erle |
if you set a property on an entity, you get network traffic |
| 12:33 |
erle |
which is hilariously inefficient. easy workaround, memoize the function. |
| 12:33 |
MTDiscord |
<Warr1024> Oh, wow, that one was never closed |
| 12:33 |
erle |
Warr1024, are you memoizing this thing? |
| 12:34 |
MTDiscord |
<Warr1024> I just use get_properties and do a comparison. |
| 12:34 |
erle |
yeah that works |
| 12:34 |
erle |
maybe we should do a general workaround library |
| 12:34 |
MTDiscord |
<Warr1024> The whole "the server doesn't keep track of obj props" argument turned out to be laughable since get_properties exists and works fine. |
| 12:34 |
erle |
for stuff that minetest either has never fixed or has fixed improperly |
| 12:35 |
MTDiscord |
<Warr1024> Haha an "should have been PRs but ?" library :-D |
| 12:35 |
erle |
not only that |
| 12:35 |
MTDiscord |
<Warr1024> I've done that elsewhere, and it's a hilarious way to make somebody else's job easier in an underhandedly hostile way. |
| 12:36 |
independent56 |
Works now! |
| 12:36 |
erle |
also stuff where lua workarounds are possible but rejected |
| 12:37 |
MTDiscord |
<Warr1024> I've probably got a lot I could pull out of NodeCore. |
| 12:37 |
MTDiscord |
<Warr1024> Also interesting is the ability to add forward-compat, which is something the engine's release cycle actually doesn't allow it to do. |
| 12:37 |
Oblomov |
(lol @ parametted) |
| 12:38 |
MTDiscord |
<Jonathon> or roadmapped |
| 12:38 |
MTDiscord |
<Warr1024> like, I made player:add_velocity work in pre-5.3 by just detecting that version and shunting the calls to player:add_player_velocity. |
| 12:38 |
erle |
roadmatted |
| 12:38 |
erle |
Warr1024 yes this is nice |
| 12:39 |
MTDiscord |
<Warr1024> heh, roadmatted is a fun umbrella term for all the various reasons something might get rejected or indefinitely deferred, which kind of dilutes the criticism of any one person :-) |
| 12:39 |
erle |
i can offer my workaround for minetest_find_nodes_in_area() |
| 12:39 |
MTDiscord |
<Warr1024> oh, there's something there that needs to be worked around? |
| 12:40 |
MTDiscord |
<Warr1024> I use that call a fair bit and have failed to notice anything significantly wrong with it. |
| 12:40 |
erle |
calling it with coords outside interval (-32768, 32767) crashes minetest before 5.5 |
| 12:40 |
erle |
so i have lua code to clamp it to that interval |
| 12:40 |
MTDiscord |
<Warr1024> ah, okay, luckily I don't think I've got any scenarios that would trigger that. |
| 12:41 |
Oblomov |
erle: but that workaround will break when the INIFITE WORLD patchset get merged |
| 12:41 |
MTDiscord |
<Warr1024> Clamping it would be good in a general-purpose library |
| 12:41 |
MTDiscord |
<Warr1024> If they expand the absolute world limits then the workaround library would very likely respond very quickly to that. |
| 12:42 |
MTDiscord |
<Warr1024> besides, when things like hash_node_position have to be reworked anyway, I think the engine/builtin would still have the hardest time of it. |
| 12:42 |
erle |
Warr1024 https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/MISC/mcl_engine_workarounds/init.lua |
| 12:43 |
erle |
it is easy to distinguish between minetest versions though |
| 12:43 |
erle |
in a library |
| 12:43 |
erle |
and infinite world would probably be a thing for a feature table |
| 12:43 |
MTDiscord |
<Warr1024> that "deep compare" function could use an option to account for float/double rounding so you can use it to compare set_properties to get_properties :-D |
| 12:44 |
MTDiscord |
<Warr1024> My object:set_properties workaround has to accept that values coming from the engine might be slightly off, so I just have an arbitrary fudge factor in there. |
| 12:44 |
erle |
look this is ghetto tier code |
| 12:44 |
erle |
oh does your thing also deal with the funny case where the engine gives you values that explode lua once they are given to a function? |
| 12:44 |
erle |
this can happen for positions |
| 12:45 |
MTDiscord |
<Warr1024> I've never seen the engine give me a pos that causes lua to do anything notably apeshit, no. |
| 12:45 |
erle |
well, it's minetest that goes apeshit, via lua |
| 12:46 |
erle |
well, there are a few positions (at least 6 i think) where you as a player can be and getting the player position will give you a value that will crash the game when you give it to a function that takes a player position |
| 12:46 |
MTDiscord |
<Warr1024> I mean I don't keep a record of every crash I've ever seen, so if it's rare and hard to repro... |
| 12:46 |
definitelya |
erle: Hood codin'. |
| 12:47 |
Oblomov |
cooding |
| 12:47 |
MTDiscord |
<Warr1024> "function that takes a player position" like trying to obj:set_pos() another entity to that position or something? |
| 12:47 |
erle |
Warr1024 you will find 1 of those positions if you move outwards beyond the map boundaries (by means of .teleport in a hacked client for example, or just normally noclip fly) and do “get pos / set pos” in a globalstep or so every 10 seconds |
| 12:47 |
erle |
yeah |
| 12:47 |
erle |
it's pretty far out though |
| 12:47 |
erle |
i bet i made a bug report about this let me check |
| 12:47 |
MTDiscord |
<Warr1024> Oh, like, approaching or exceeding the 32k limit? |
| 12:47 |
erle |
no, far more out |
| 12:48 |
|
kamdard joined #minetest |
| 12:48 |
definitelya |
You probably did lol. |
| 12:48 |
erle |
it's an improper conversion |
| 12:48 |
definitelya |
You made mso many. |
| 12:48 |
MTDiscord |
<Warr1024> I'dn't be surprised if those 32k limits are deeply assumed within the engine at various layers and lots of stuff breaks if you violate that. It actually seems weird to me that any objects are allowed beyond those limits at all in the first place. |
| 12:48 |
erle |
well i stopped making them at some point |
| 12:48 |
definitelya |
s/mso/so |
| 12:48 |
definitelya |
true |
| 12:48 |
erle |
no it's not 32k limit. player positions have several representations. |
| 12:49 |
erle |
definitelya everytime i decide to make 1 bug report i make 5 in the end and lose several hours of life to debug it, so i stopped doing it for the time being. i have low energy. |
| 12:49 |
MTDiscord |
<Warr1024> Yeah, I guess what I'm saying is that if they were going to hard-code the 32k limit so deeply, they might as well have clamped the boundaries regardless of representation. |
| 12:49 |
erle |
no, it's a different thing |
| 12:49 |
MTDiscord |
<Warr1024> In a way maybe it's good that they didn't, but of course that only removes the easy obstacles to boundary expansion. |
| 12:49 |
definitelya |
erle: Ah, gotcha. |
| 12:49 |
erle |
entity/player positions are floats and they are “clamped” separately |
| 12:50 |
erle |
definitelya it has nothing to do with how fast the bug reports are addressed or so, it's just that debugging is a rabbit hole |
| 12:50 |
|
riff_IRC joined #minetest |
| 12:51 |
erle |
Warr1024 i believe it is this https://github.com/minetest/minetest/issues/11742 |
| 12:51 |
MTDiscord |
<Warr1024> funnily enough, I've actually never really seen much point to 32-bit floats as a data type. Every time I've wanted a floating point number, I pretty much always just start with a double, and apparently the designers of languages like js or lua seem to agree. |
| 12:51 |
Oblomov |
Warr1024: you're obviously too young |
| 12:52 |
erle |
> the problem is that player:get_pos() can return a position that minetest.get_objects_inside_radius() can not use |
| 12:52 |
MTDiscord |
<Warr1024> Haha, it's super rare that I ever get called "too young" |
| 12:52 |
Oblomov |
there's several excellent reasons for fp32: higher performance, lower memory footprint being the primary two |
| 12:52 |
MTDiscord |
<Warr1024> No, I have never had to conserve space on a punchcard, but I'm not all that young. |
| 12:52 |
Oblomov |
8-D |
| 12:53 |
erle |
the problem is that not all positions roundtrip through the serialization |
| 12:53 |
erle |
this will be an issue with bigger world sizes |
| 12:53 |
Oblomov |
I use fp32 everywhere, but I mostly write GPU HPC code, so the impact of fp64 vs fp32 is SIGNIFICANT |
| 12:53 |
erle |
obviously |
| 12:53 |
MTDiscord |
<Warr1024> erle is correct though that regardless of what's going on under the hood, an API spitting out a value that causes that same API to choke when it's passed back in unmodified is just embarrassing at the least :-) |
| 12:53 |
Oblomov |
oh that's definitely true |
| 12:54 |
MTDiscord |
<Warr1024> Eh, maybe I just don't use floats because I do very little front-end work. I know that I see them very rarely in the wild EXCEPT for GUIs where they're used for positions and sizes quite often. |
| 12:54 |
Oblomov |
honestly I would keep the player pos representation as 32-bit int for the node coords + fp32 position within the node |
| 12:54 |
Oblomov |
but this would require rewriting the entire lua stack |
| 12:54 |
erle |
floats are a good data type. there are only 4 billion of them and floats are fast, so you can unit test them all. |
| 12:55 |
|
lemonzest joined #minetest |
| 12:55 |
MTDiscord |
<Warr1024> If it were me I'd probably make the player pos 64-bit floats. If you ever get enough players on at the same time that the memory or perf impact of those is significant, you've got a Good Problem To Have. |
| 12:55 |
|
independent_ joined #minetest |
| 12:56 |
Oblomov |
(also 32 bits of precision for the local fraction of node is too much, maybe 32 + 8 would be enough but would need an fp8 library) |
| 12:56 |
MTDiscord |
<Warr1024> It's also way simpler than the int+float approach |
| 12:56 |
Oblomov |
Warr1024: the patchset to expand the world size to 32-bit^3 does that |
| 12:56 |
Oblomov |
Warr1024: int+float has uniform accuracy throughout the domain, fp64 is less accurate towards the edge of the domain |
| 12:56 |
MTDiscord |
<Warr1024> I doubt that 32+8 would be any better than 32+32, aside from giving you the option to pack it more tightly for storage. |
| 12:57 |
Oblomov |
yeah,32+8 would just be a way to spare storate/network |
| 12:57 |
MTDiscord |
<Warr1024> fp64 would go from having way too much precision near the center of the domain to only moderately too much precision toward the edge. It's pretty far down on my list of concerns. |
| 12:57 |
Oblomov |
also 40 bits fit well in a fp64 |
| 12:57 |
celeron55 |
floats are common on less powerful systems like cortex m3 (which doesn't even have an FPU) and cortex m4 (which only supports float, not double) |
| 12:58 |
celeron55 |
as for minetest, it probably only matters in terms of memory footprint |
| 12:58 |
celeron55 |
and network footprint |
| 12:58 |
celeron55 |
(and storage footprint) |
| 12:58 |
Oblomov |
well, fp64 would have the same memory and network footprint as 32+32 |
| 12:59 |
MTDiscord |
<Warr1024> I mean in any event you'd just have a number abstraction and use that, but in the absence of specific compelling evidence to use a more complex one, I'd just use f64 as a starting point. |
| 12:59 |
Oblomov |
32+32 would be beneficial for hw without fp64 support, but then lua needs to be rewritten |
| 12:59 |
celeron55 |
i'm enough of an embedded systems programmer to always start with float |
| 12:59 |
Oblomov |
s/lua/the lua code in mt/ obviously |
| 13:00 |
MTDiscord |
<Warr1024> I would be surprised if float support is the biggest obstacle to MT running on systems that it currently doesn't run on though. |
| 13:00 |
Oblomov |
in fact, for the level of accuracy we need within a node, we might just as well do fixed point |
| 13:01 |
Oblomov |
(32+8 again?) |
| 13:01 |
MTDiscord |
<Warr1024> 32-bit fixed point would actually be ideal for things like sending rounded player/ent positions over the network. You'd still want some excess precision internally to prevent rounding from compounding. |
| 13:02 |
Oblomov |
you can do 64-bit fixed point internally for the extra precision |
| 13:02 |
MTDiscord |
<Warr1024> I think you could represent an object's position with 24 bits of fixed point and it would be very hard to notice the rounding. |
| 13:03 |
Oblomov |
anyway, all this I think is moot since I doubt there's any intention to blow up the lua api completely |
| 13:03 |
Oblomov |
unless there's an intention to start migrating now |
| 13:03 |
Oblomov |
plan for something that will transitiononly 5-10 years down the line |
| 13:04 |
MTDiscord |
<Warr1024> I mean it could be a thing where you just convert stuff to/from double for Lua only and use other representations elsewhere, but I just seriously doubt that there's enough value to that to make it worth the trouble. |
| 13:05 |
MTDiscord |
<Warr1024> The only way that a 5 year plan isn't drastically modified over those 5 years would be if you more or less didn't actually execute on it :-) |
| 13:05 |
Oblomov |
it would fit with the rethinking of the world coordinate system to allow larger domains though |
| 13:05 |
erle |
celeron55 how do you deal with people who write bad floating point code and then use that as a justification to write more bad floating point code because “floating point is inaccurate anyways”? |
| 13:05 |
erle |
celeron55 also do you know any more gotchas than the x87 gcc FPU rounding fuckup? |
| 13:08 |
|
fling joined #minetest |
| 13:10 |
|
tech_exorcist joined #minetest |
| 13:11 |
|
riff-IRC joined #minetest |
| 13:14 |
|
RhineDevil^ joined #minetest |
| 13:48 |
|
harry-wood joined #minetest |
| 13:57 |
|
appguru joined #minetest |
| 14:08 |
|
submariner_ joined #minetest |
| 14:10 |
|
fling joined #minetest |
| 14:15 |
|
sinvet joined #minetest |
| 14:21 |
|
harry-wood joined #minetest |
| 14:23 |
|
sinvet joined #minetest |
| 14:33 |
|
submariner_ joined #minetest |
| 14:37 |
|
sinvet joined #minetest |
| 14:41 |
definitelya |
I have a devious plan... |
| 14:41 |
definitelya |
Now that Twitter got musked, we could target Elon with Minetest related content, so he'd be likely to share it on his platform and make others interested! |
| 14:43 |
lagash |
Does he even play Minecraft? |
| 14:43 |
definitelya |
It's foolproof I tell you. |
| 14:53 |
|
Taoki joined #minetest |
| 14:58 |
mmuller |
build some models of his cars and rockets in MT and you might just be onto something. |
| 14:59 |
mmuller |
Also, lol at "Twitter got musked" |
| 15:02 |
definitelya |
;) |
| 15:05 |
|
___nick___ joined #minetest |
| 15:09 |
independent_ |
Items seem to be skipping a pipe t-junction into empty drawers |
| 15:11 |
independent_ |
https://youtu.be/o5FrG36ITrs |
| 15:14 |
|
fling joined #minetest |
| 15:20 |
|
fluxionary joined #minetest |
| 15:32 |
|
Verticen joined #minetest |
| 15:39 |
|
gpcf joined #minetest |
| 15:50 |
Pexin |
how much musk must a muskrat musk if a muskrat must musk much? |
| 15:57 |
|
sobkas joined #minetest |
| 16:02 |
|
independent_ joined #minetest |
| 16:03 |
|
Extex joined #minetest |
| 16:19 |
|
harry-wood joined #minetest |
| 16:20 |
|
fling joined #minetest |
| 16:27 |
|
chilledfrogs joined #minetest |
| 16:34 |
|
tech_exorcist joined #minetest |
| 16:36 |
|
Desour joined #minetest |
| 16:38 |
|
Yad joined #minetest |
| 16:46 |
|
Talkless joined #minetest |
| 16:53 |
|
z812 joined #minetest |
| 17:07 |
|
Yad joined #minetest |
| 17:11 |
|
harry-wood joined #minetest |
| 17:22 |
|
fling joined #minetest |
| 17:23 |
|
Gustavo6046 joined #minetest |
| 17:25 |
|
Gustavo6046 joined #minetest |
| 17:26 |
|
cation joined #minetest |
| 17:28 |
|
Alias joined #minetest |
| 17:30 |
|
sobkas joined #minetest |
| 17:38 |
|
kabou joined #minetest |
| 17:43 |
sfan5 |
quick: someone suggest a table deep equal implementation in Lua |
| 17:45 |
Krock |
copy table.copy |
| 17:45 |
Krock |
but run compare rather than assign |
| 17:45 |
Krock |
is that quick enough? |
| 17:47 |
sfan5 |
might be |
| 17:47 |
Oblomov |
serialize sorting keys and compare the strings 8-D |
| 17:48 |
|
Verticen joined #minetest |
| 17:50 |
Desour |
eq(a1, a2, et) et=et or {} if a1==a2 then return end if type(a1)~="table"or type(a2)~="table"then return false end if et[a1]and et[a1][a2]then return true end et[a1]=et[a1]or{}et[a1][a2]=true et[a2]=et[a2]or{}et[a2][a1]=true for k,v in pairs(a1)do if not eq(a2[k],v,et) then return false end for k,v in pairs(a2)do if not eq(a1[k],v,et) then return false end end |
| 17:51 |
Desour |
^ something like this maybe |
| 17:52 |
Desour |
but, do you want for example {[{}]=1} and {[{}]=1} to be equal? |
| 17:53 |
sfan5 |
tables should be compared by contents, not identity |
| 17:53 |
sfan5 |
oh but you point is Lua does that differently |
| 17:53 |
sfan5 |
whatever, I don't plan to do that |
| 17:53 |
sfan5 |
+r |
| 17:54 |
Krock |
next up challenge: compare functions by their original name (using the function ID/address as input) |
| 17:55 |
Desour |
Krock: you have debug.getinfo in minetest https://www.lua.org/manual/5.1/manual.html#pdf-debug.getinfo |
| 17:59 |
Krock |
oh nice |
| 18:04 |
|
grouinos joined #minetest |
| 18:04 |
Desour |
you could also look at how luassert (used by busted) does its compare: https://github.com/Olivine-Labs/luassert/blob/e2ab0d218d7a63bbaa2fdebfa861c24a48451e9d/src/util.lua#L12 |
| 18:05 |
|
Gustavo6046 joined #minetest |
| 18:05 |
sfan5 |
wrote my own https://0x0.st/obmM.png |
| 18:19 |
sfan5 |
fixing the two syntax errors is left as an exercise to the reader |
| 18:22 |
Oblomov |
I would do it sligthly differently |
| 18:23 |
Oblomov |
if type(a) ~= type(b) then return false |
| 18:23 |
Oblomov |
if type(a) ~= 'table' then return a == b |
| 18:23 |
Oblomov |
and then the deepequal |
| 18:28 |
|
fling joined #minetest |
| 18:28 |
|
wolfshappen joined #minetest |
| 18:28 |
MTDiscord |
<luatic> for - then :D |
| 18:29 |
MTDiscord |
<luatic> anyways sfan5: modlib has three deep equality implementations based on what you need |
| 18:29 |
sfan5 |
I don't plan to import modlib into devtest ;) |
| 18:29 |
MTDiscord |
<luatic> What you got there is basically a shorter version of equals_noncircular |
| 18:29 |
MTDiscord |
<luatic> sfan5: I wouldn't want you to |
| 18:31 |
MTDiscord |
<luatic> Anyways, should you ever need a deep equality check which deals properly with circular tables (which first needs to be defined), consider having a look at https://github.com/appgurueu/modlib/blob/b7ae328aab904c009457f9d04aad003da1557421/table.lua and https://github.com/appgurueu/modlib/blob/b7ae328aab904c009457f9d04aad003da1557421/table.lua |
| 18:31 |
MTDiscord |
<luatic> Looking back I'm somewhat ashamed of the time complexity though |
| 18:32 |
MTDiscord |
<luatic> TL;DR: Circular refs & table keys are nasty (BTW your impl. won't properly deal with table keys as during indexing it'll go by identity) |
| 18:44 |
|
Flabb joined #minetest |
| 18:55 |
|
___nick___ joined #minetest |
| 18:56 |
|
CWz joined #minetest |
| 18:57 |
|
___nick___ joined #minetest |
| 19:20 |
|
independent_ joined #minetest |
| 19:22 |
independent_ |
Why does water take so much memory? |
| 19:23 |
independent_ |
I make a massive water deluge system for forest fires and now the server crawls |
| 19:23 |
independent_ |
I wish it was made more efficent |
| 19:30 |
|
fling joined #minetest |
| 19:57 |
|
riff-IRC joined #minetest |
| 20:11 |
|
harry-wood joined #minetest |
| 20:21 |
|
Gustavo6046 joined #minetest |
| 20:33 |
jonadab |
Are you sure it's the memory usage that's causing the slowness? I was under the impression that flowing water has to be regularly checked to see whether it should flow differently. |
| 20:34 |
|
fling joined #minetest |
| 20:43 |
independent_ |
Ah, makes snese |
| 21:00 |
|
illwieckz joined #minetest |
| 21:07 |
|
sobkas joined #minetest |
| 21:14 |
|
illwieckz joined #minetest |
| 21:18 |
|
harry-wood joined #minetest |
| 21:23 |
|
proller joined #minetest |
| 21:40 |
|
fling joined #minetest |
| 21:44 |
|
specing joined #minetest |
| 22:00 |
|
Sven_vB joined #minetest |
| 22:18 |
|
Oksanaa joined #minetest |
| 22:32 |
|
panwolfram joined #minetest |
| 22:40 |
independent_ |
Where are the docs for the digilines API for street's signals? |
| 22:41 |
|
proller joined #minetest |
| 22:41 |
independent_ |
Or do i have to read the code like someone without documentation? |
| 22:43 |
MTDiscord |
<Jonathon> the latter basically |
| 22:43 |
|
fling_ joined #minetest |
| 22:43 |
MTDiscord |
<Jonathon> digilines has a small wiki |
| 22:43 |
MTDiscord |
<Jonathon> https://github.com/minetest-mods/digilines/wiki |
| 22:45 |
MTDiscord |
<Warr1024> For every 20 people asking about documentation or complaining about the lack of any, there's 0 to 1 actually writing any... |
| 22:45 |
MTDiscord |
<Jonathon> relevant issue https://github.com/minetest-mods/digilines/issues/74, doesnt help the mod is held in a mostly dead org |
| 22:47 |
independent_ |
I'll write some on my wiki |
| 22:47 |
MTDiscord |
<GreenXenith> Just because minetest-mods has a separate direction from mt-mods doesnt make it a dead org. It was updated yesterday, and frequently before that. Please stop whining about minetest-mods. |
| 22:48 |
MTDiscord |
<Jonathon> didnt say it was dead, said mostly |
| 22:49 |
MTDiscord |
<GreenXenith> Any kind of dead doesnt apply to a repo that gets updates at least every few days |
| 22:49 |
MTDiscord |
<Jonathon> lately it has been a bit more active |
| 22:49 |
MTDiscord |
<Jonathon> hopefully that improves |
| 23:07 |
|
ronoaldo joined #minetest |
| 23:26 |
|
AliasAlreadyTake joined #minetest |
| 23:50 |
|
kamdard joined #minetest |
